home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11766 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.8 KB  |  98 lines
  1. Path: tick.cs.wm.edu!news
  2. From: mhagger@yellow.physics.wm.edu (Michael Haggerty)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Inheritance and function signatures
  5. Date: 15 Mar 1996 20:54:31 -0500
  6. Organization: College of William and Mary
  7. Sender: mhagger@yellow.physics.wm.edu
  8. Message-ID: <x1lol1x0o8.fsf@yellow.physics.wm.edu>
  9. References: <MANOWAR.96Mar11132010@dilo.engin.umich.edu>
  10.     <3146D380.2781@rchland.ibm.com>
  11. Reply-To: mhagger@mail.delos.physics.wm.edu
  12. NNTP-Posting-Host: yellow.physics.wm.edu
  13. In-reply-to: Philip Staite's message of Wed, 13 Mar 1996 07:54:08 -0600
  14. X-Newsreader: Gnus v5.1
  15.  
  16. Hello,
  17.  
  18. In article <3146D380.2781@rchland.ibm.com> Philip Staite
  19. <pstaite+@rchland.ibm.com> writes:
  20.  
  21. > Basically within the scope of B the print(int,int) "captures" the name
  22. > print -- all references to print() go to it.  Here's the FAQ that covers
  23. > this:
  24. > 
  25. > ===========================================================================
  26. > 
  27. > Q63: What's the meaning of, "Warning: Derived::f(int) hides
  28. > Base::f(float)"?
  29. > 
  30. > It means you're going to die.
  31. > 
  32. > Here's the mess you're in: if Derived declares a member function
  33. > named "f", and Base declares a member function named "f" with a
  34. > different signature (e.g., different parameter types and/or
  35. > constness), then the Base "f" is "hidden" rather than "overloaded"
  36. > or "overridden" (even if the Base "f" is virtual).
  37. > 
  38. > Here's how you get out of the mess: Derived must redefine the Base
  39. > member function(s) that are hidden (even if they are non-virtual).
  40. > Normally this re-definition merely calls the appropriate Base member
  41. > function.  E.g.,
  42. > 
  43. >     class Base {
  44. >     public:
  45. >       void f(int);
  46. >     };
  47. > 
  48. >     class Derived : public Base {
  49. >     public:
  50. >       void f(double);
  51. >       void f(int i) { Base::f(i); }
  52. >     };             // ^^^^^^^^^^--- redefinition merely calls Base::f(int)
  53. > 
  54. > ===========================================================================
  55.  
  56. I have a question on this point.
  57.  
  58. Is it sufficient to do the following:
  59.  
  60.     // example 1:
  61.     class Base {
  62.     public:
  63.       void f(int);
  64.     };
  65.  
  66.     class Derived : public Base {
  67.     public:
  68.       Base::f; // put Base::f in Derived's namespace
  69.       void f(double); // add a new signature for f
  70.     };
  71.  
  72. ?  If not, why not?  It seems to me that this is a good and logical
  73. feature.
  74.  
  75. The reason it would be nice is for the case of an abstract base class
  76. hierarchy:
  77.  
  78.     // example 2:
  79.     class Base {
  80.     public:
  81.       virtual void f(int) = 0;
  82.     };
  83.  
  84.     class Derived : public Base {
  85.     public:
  86.       virtual void f(double) = 0;
  87.       void f(int i) { Base::f(i); } // OOPS!
  88.     };
  89.  
  90. As I understand it, example 2 is illegal since it attempts to call
  91. (non-virtually) Base::f(int), which doesn't exist at all.  Or is there
  92. some twist in the rules that makes example 2 legal with the right
  93. behavior?
  94.  
  95. I submit that there ought to be a way to do this...
  96.  
  97. --Michael
  98.